1. Field of the Invention
The present invention relates to the field of application servers, and more particularly to a system and method for caching JavaServer Pages(trademark) responses.
2. Description of the Related Art
The field of application servers has recently become one of the fastest-growing and most important fields in the computing industry. As web applications and other distributed applications have evolved into large-scale applications that demand more sophisticated computing services, specialized application servers have become necessary, in order to provide a platform supporting these large-scale applications. Applications that run on application servers are generally constructed according to an n-tier architecture, in which presentation, business logic, and data access layers are kept separate. The application server space is sometimes referred to as xe2x80x9cmiddlewarexe2x80x9d, since application servers are often responsible for deploying and running the business logic layer and for interacting with and integrating various enterprise-wide resources, such as web servers, databases, and legacy systems.
Application servers offer significant advantages over previous approaches to implementing web applications, such as using common gateway interface (CGI) scripts or programs. FIG. 1 illustrates a typical architecture for a web application utilizing CGI scripts or programs. The client computer running a web browser 10 may reference a CGI program 18 on the web server 14, e.g., by referencing a URL such as xe2x80x9chttp://server.domain.com/cgi-bin/myprogram.plxe2x80x9d over an Intranet or the Internet 12. Generally, the CGI program runs on the web server itself, possibly accessing a database 20, e.g. in order to dynamically generate HTML content, and the web server returns the output of the program to the web browser. One drawback to this approach is that the web server may start a new process each time a CGI program or script is invoked, which can result in a high processing overhead, impose a limit on the number of CGI programs that can run at a given time, and slow down the performance of the web server. In contrast, application servers typically provide a means for enabling programs or program components that are referenced via a URL to run on a separate computer from the web server and to persist between client invocations.
Another common drawback of previous web application design models, such as the use of CGI programs, is related to data access. For example, if a CGI program needs to access a database, the program typically opens a database connection and then closes the connection once it is done. Since opening and closing database connections are expensive operations, these operations may further decrease the performance of the web server each time a CGI program runs. In contrast, application servers typically provide a means to pool database connections, thus eliminating or reducing the need to constantly open/close database connections. Also, data access in CGI programs is generally coded at a relatively low level, e.g., using a specific dialect of SQL to access a specific type of database. Thus, portions of the application may need to be recoded if the database is replaced with a new type of database. Application servers, on the other hand, may provide a database service for applications to utilize as an interface between the application and the database, which can serve to abstract the application from a particular type of database.
Application servers may also provide many other types of application services or may provide standard reusable components for tasks that web applications commonly need to perform. Application servers often incorporate these services and components into an integrated development environment specialized for creating web applications. The integrated development environment may leverage various standard software component models, such as the Common Object Request Broker Architecture (CORBA), the (Distributed) Component Object Model (COM/DCOM), Enterprise JavaBeans(trademark) (EJB), etc., or the integrated development environment may provide its own software component model or may extend standard component models in various ways.
The following list is a partial list of the types of application services or application components that application servers may provide. By leveraging these types of integrated, pre-built services and components, web application developers may realize a significant reduction in application development time and may also be able to develop a more robust, bug-free application. Application servers from different vendors differ, of course, in the types of services they provide; thus, the following list is exemplary only.
As noted above, application servers may provide data access services for accessing various types of databases, e.g. through directly supporting proprietary databases, such as SAP, Lotus Notes, CICS, etc., or through standardized interfaces, such as ODBC, JDBC, etc. Also, as noted above, application servers may enable database connection pooling or caching.
Application servers may also provide services for accessing network directories, such as directories that support the standard Lightweight Directory Access Protocol (LDAP).
Application servers may also provide application security services or components. Web application security may be considered at different levels, such as: client-to-server communication, application-level privileges, database access, directory service access, etc. Application server security-related services/components may include support for performing user authentication, performing data encryption, communicating via secure protocols such as Secure Sockets Layer (SSL), utilizing security certificates, programming user access rights, integrating with operating system security, etc.
Application servers may also provide services enabling a web application to easily maintain user state information during a user session or across user sessions. Performing state and session management is especially important for applications that have complex, multi-step transactions.
Application servers may also support caching the results of application logic execution or caching the results of web page/component output, so that for appropriate subsequent requests, the results may be reused.
Application servers may also support result streaming, such as dynamically streaming HTTP output, which may be especially useful for large result sets involving lengthy queries. A related service may enable an application to easily display a large result set by breaking the result set down into smaller groups and displaying these groups to the user one at a time.
Many web applications need to perform various types of searching or indexing operations. Application servers may also provide application services for indexing or searching various types of documents, databases, etc.
As noted above, many web applications may perform various types of complex, multi-step transactions. Application servers may also provide support for managing these application transactions. For example, this support may be provided via a software component model supported by the application server, such as the Enterprise JavaBeans(trademark) component model, or via integration with third-party transaction process monitors, etc.
It is often desirable to enable web applications to perform certain operations independently, as opposed to in response to a user request. For example, it may be desirable for an application to automatically send a newsletter to users via email at regularly scheduled intervals. Application servers may support the creation and scheduling of events to perform various types of operations.
Many types of web applications need to perform e-commerce transactions, such as credit card transactions, financial data exchange, etc. Application servers may provide services for performing various types of e-commerce transactions or may provide an integrated third-party e-commerce package for applications to use.
Web applications often need to utilize various types of standard network application services, such as an email service, FTP service, etc. Application servers may provide these types of services and may enable applications to easily integrate with the services.
Web applications often need to log various conditions or events. Application servers may provide an integrated logging service for web applications to use.
Judging by the exemplary list above of computing services that application servers may provide for web applications, it is apparent that application servers may integrate a diverse range of services, where these services may interact with many different types of servers, systems, or other services. For example, an application server may act as a platform hub connecting web servers, database servers/services, e-commerce servers/services, legacy systems, or any of various other types of systems or services. A key benefit of many application servers is that they not only provide this service/system integration, but typically also provide centralized administrative or management tools for performing various aspects of system and application administration.
For example, application servers may provide management tools related to application development and deployment, such as tools for source code control and versioning, bug tracking, workgroup development, etc. Application servers may also provide tools related to application testing and deployment, such as tools for application prototyping, load simulation, dynamic code base updates, etc. Application servers may also provide tools for easily configuring the application to utilize various of the application server services described above. For example, administrators may use a tool to set the result caching criteria for particular application components or pages, or may use a tool to specify which documents to index or to specify indexing methods, etc.
One important class of application server administrative tools pertains to real-time application management and monitoring. Application servers may provide tools for dynamically managing various factors affecting application performance, e.g. by adjusting the application services and support features described above. For example, application server tools may allow administrators to:
dynamically adjust the number of database connections maintained in a database pool, in order to determine the optimum pool size for maximum performance
clear or resize application output caches
dynamically change various aspects of system or application security
schedule or trigger events, such as events for sending e-mail reports to application users, generating reports based on collected data, etc.
start and stop various application services, such as email or FTP services, from a centralized user interface
This list is, of course, exemplary, and particular application servers may support different types of centralized application management.
In addition to the factors discussed above, many application servers also include means for providing various types of system reliability and fault tolerance. One common technique related to fault tolerance is known as application server xe2x80x9cclusteringxe2x80x9d. Application server clustering refers to tying together two or more application servers into a system. In some cases, this xe2x80x9ctying togetherxe2x80x9d may mean that application code, such as particular software components, is replicated on multiple application servers in a cluster, so that in the case of a hardware or software failure on one application server, user requests may be routed to and processed by other application servers in the cluster.
Application server clustering may also facilitate application performance and scalability. Application servers may be added to a cluster in order to scale up the available processing power by distributing work. Advantageously, application servers often enable this type of scaling up to be down without requiring changes to the application code itself.
Work may be distributed across an application server cluster in different ways. For example, as discussed above, application code may be replicated across multiple application servers in the cluster, enabling a given request to be processed by any of these multiple application servers. Also, application code may be logically partitioned over multiple servers, e.g., so that a particular application server is responsible for performing particular types of operations. This type of application partitioning may help application performance in various ways. For example, application partitioning may reduce the need for an application server to perform context switching between different types of operations, such as CPU-intensive operations versus input/output-intensive operations. Also, application partitioning may be used to match application processing to various physical characteristics of a system, such as network characteristics. For example, data-intensive application logic may be configured to run on an application server that is closest to a data source, in order to reduce the latencies associated with accessing remotely located data.
In the case of application code replication, where multiple application servers are capable of processing a given request, it is often desirable to route the request to the xe2x80x9cbestxe2x80x9d application server currently available to process the request, i.e., to the application server that will enable the request to be processed and the request results to be returned to the client as quickly as possible. This mapping of client requests to application servers is known as application server load balancing.
As noted above, application servers may support caching the results of application logic execution or caching the results of web page/component output, so that for appropriate subsequent requests, the results may be reused. Given the types of applications that may run on application servers, such as web applications, this type of output caching may significantly enhance the performance of an application.
One type of component supported by many application servers is JavaServer Page(trademark) components. JavaServer Pages(trademark) (JSP) is a Java(trademark) platform technology for building applications streaming dynamic content such as HTML, DHTML, XHTML and XML. JavaServer Pages is a Standard Extension that is defined on top of the Servlet Standard Extension. JSP 1.1 uses the classes from Java Servlet 2.1 specification. For more information on JavaServer Pages(trademark), please refer to the JavaServer Pages(trademark) Specification, Version 1.1, available from Sun Microsystems, Inc.
Although some existing application servers support output caching for JavaServer Pages(trademark) responses, previous approaches to JSP response caching often suffer from various drawbacks. For example, it may be desirable to enable programmers to specify the response-caching criteria for each JSP component using a flexible programmatic means. It may also be desirable to improve upon the algorithms used to determine whether cached responses satisfy requests, in order to enhance performance.
The problems outlined above may in large part be solved by a system and method for caching JavaServer Page(trademark) (JSP) component responses, as described herein. The JSP components may be components that execute on an application server that supports networked applications, such as web applications or other Internet-based applications. One or more client computers, e.g., web servers, may perform requests referencing the JSP components on the application server. The system may also be configured to utilize a cluster of application servers in which requests from the client computer(s) are distributed across different application servers.
The execution of JSP components may be managed by a JSP engine process running on the application server. When a request referencing a JSP is received from a client computer, the JSP engine may first check a JSP response cache to determine whether a valid JSP response satisfying the request is present. A JSP request may comprise various types of attributes, such as variable name and value pairs, that are matched against criteria sets associated with each response entry. If a matching cached response is found, then the response may be retrieved and immediately streamed back to the client. Otherwise, the referenced JSP may be executed.
Each JSP file may comprise code for specifying caching criteria for the JSP. This code may cause the output (or response) for the JSP to be cached once the JSP execution is complete, where the cache entry is associated with the specified caching criteria. The caching criteria may then be used to match against attributes of future JSP requests, as described above. The caching criteria may include a xe2x80x9ctimexe2x80x9d argument indicating the number of seconds for which the cached response should be considered valid, a criteria string specifying attribute criteria to use in determining whether or not the cached response may be used to satisfy a request, etc. In particular embodiments, any of various types of cache criteria may be supported, as described below. The caching criteria may be specified in the JSP code in various ways, e.g., by a method invocation, by using markup tags, etc.